A module installed in a work profile or a private space was never shown the
System Framework row, so the one target it may actually need — Core Patch
and friends hook nothing else — was unreachable from anywhere but the owner
user. The scope editor gated the row on `userId == 0`, inherited from the
legacy manager.

The gate was only ever in the manager. Tracing the rest before changing it:
ConfigCache maps any `system` scope row straight to
ProcessScope("system_server", 1000) without looking at whose module it is,
so a module in user 10 is loaded into system_server perfectly well once the
row exists. That is worth stating, because the daemon half of PR #356 was
never written and the issue thread reads as though it were the obstacle. It
is not; there was one line to change and it was here.

The row is stored against user 0 whoever ticks it, because there is exactly
one system_server on the device. It is not a per-user target that other
users happen to lack — it is one process they all share, which the row now
says out loud. Someone editing a work profile module's scope has no other
way to learn that this particular target is not scoped to their profile.

The daemon now normalises `("system", n)` to `("system", 0)` rather than
dropping the row. Dropping meant that restoring a backup written by an
older manager, which recorded the framework under the module's own user,
silently lost the one target the module cared about — and said nothing.

PR #356 fixes the same thing in app/ScopeAdapter.java, which no longer
exists; it should be closed in favour of this rather than merged.

Verified on device: the row renders with its explanation. The non-owner
case is reasoned from the code, not exercised — the private space on this
device is locked and the tree is shared with another change in flight.